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Abstract 

I present a substitution algorithm for the simply-typed A-calculus, represented in the 
style of Altenkirch and Reus (1999) which is statically guaranteed to respect scope and 
type. Moreover, I use a single traversal function, instantiated first to renaming, then to 
substitution. The program is written in Epigram (McBride & McKinna, 2004). 



1 Introduction 

In this paper, I give a small but indicative example of programming with inductive 
families of datatypes (Dybjer, 1991) in the dependcntly typed functional program- 
ming language, Epigram (McBride & McKinna, 2004). I present type-preserving 
renaming and substitution for the type-correct representation of the simply-typed 
A-calculus given by Altenkirch and Reus (1999). I should draw attention to two 
aspects of this program: 

• Renaming and substitution turn out to be instances of a single traversal 
operation, pushing functions from variables to 'stuff' through terms, for a 
suitable notion of 'stuff'. This traversal operation is structually recursive, 
hence clearly total. 

• Type preservation is clearly promised by the types of these programs; in their 
bodies, the amount of syntax required to fulfil this promise is none whatsoever. 
The ill-concealed ulterior motive of this paper is to put Epigram's notational 
innovations through their paces. 

The only significant cosmetic treatment I have given the code is to delete a few 
brackets and make some of the operators infix: the honest ASCII thus looks a little 
clumsier. I suppressed no details: the process usually referred to vaguely as 'type 
inference' is hard at work here, inferring values determined by the dependent types 
in which they occur. 

2 Simply Typed A- Calculus 

Figure 2 gives the now traditional definition of the type-correct simply-typed A- 
terms in Epigram's two-dimensional syntax. The natural deduction style emphasises 
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data = where j*' ^ ' Ijf 

Ty : * • : Ty 5 t> T : Ty 



data 7= where 



T : Ctxt g : Ty 



Ctxt : * £ : Ctxt YzS : Ctxt 

data r : CtXt T : Ty where x : F B T 

data r 3 r . Jy where vz . T ._ s 3 g vs x . T . s B T 

data r : Ctxt T ■ J y 

where x : V 3 T t : TzS ► T f:T>S>T s : T ► g 

-^^varsrr^r Ida i : T ► 5 > T app si : T ► T 



Fig. 1. The Simply- Typed A-Calculus 



the connection between inductive families of datatypes and deduction systems. Each 
rule types the general usage of a new symbol, below the line, in terms of parameters 
typed above the line. You can read ':' as 'has type' and as the type of types. 

This may seem like overkill for 'simple' definitions like Ty (for simple types) and 
Ctxt (for contexts — reversed lists of simple types) , which you might imagine writing 
grammar-style, like this: 

data Ty = • | Ty >Ty 
data Ctxt = £ \ Ctxt:Ty 

The production Ty t>Ty makes perfect sense in a language where types and values 
are rigidly separated, but in Epigram it's actually a well-formed but ill-typed ap- 
plication! Our notation invites the programmer to write a set of patterns for data, 
naming their parts: these patterns and these names reappear when you edit inter- 
actively, as the machine generates exhaustive case analyses on the left-hand sides 
of programs. 

Naming becomes practically indispensable once types start to depend on val- 
ues. Moreover, inductive families of datatypes assign individual return types for 
each constructor, an unconventional practice which again leads us away from the 
conventional notation. 

Here, the '9' family presents variables as an inference system for context mem- 
bership. This representation amounts to de Bruijn indices (de Bruijn, 1972), but 
correctly typed and scoped. Meanwhile, the '►' family presents simply- typed terms 
via their typing rules, extending the context under a Ida and policing the compatil- 
ity of domain and argument in an app. Note that '::' and '>' bind more tightly than 
'9' and 

The form of a rule's conclusion quietly specifies which arguments are to be kept 
implicit and which should be shown. In the data constructors for '9' and '►', you'll 
find r, S and T undeclared — their types are inferrable from usage by standard 
techniques (Damas & Milner, 1982). Moreover, the natural deduction rule serves 
like 'let' in the Hindley- Milner system to indicate the point at which variables 
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should be generalised where possible. In effect, we may omit declarations for an 
initial segment of parameters to a rule, provided their types are inferrable. 

What has happened? The usual alignment of the implicit-versus-explicit with 
type- versus- value is so traditional that you almost forget it's a design choice. De- 
pendent types make that choice untenable, but it's not the end of the world. 



3 Renaming and Substitution, Together 

Renaming and substitution are both term traversals, lifting an operation on vari- 
ables structurally to the corresponding operation on terms. Each must perform an 
appropriate lifting to push an operation under a Ida. Where these operations differ 
is in the image of variables: renamings map variables to variables and susbtitu- 
tions map variables to terms. Here, I abstract the pattern, showing how to traverse 
terms, mapping variables to any stuff which supports the necessary equipment. 
What's stuff? It's a type family '♦' indexed by Ctxt and Ty. What's the necessary 
equipment? Here it is: 



G : Ctxt T : Ty 
G ♦ T : * 

to Kit (♦) : * 



(♦) 



T 9 T i : T ♦ T i : T ♦ T 



r ♦ T tmi : T ► T wk i : T:S ♦ T 

kit vr tm wk : Kit (♦) 



We need '♦'to support three things: a mapping in from the variables, a mapping 
out to the terms and a weakening map which extends the context. Renaming will 
instantiate '♦' with '9'; for substitution, we may choose l Tm' instead. Now we need 
to show how to traverse terms with any Kit, and how to build the Kits we need. 

By the way, you may have noticed that I have nested natural deduction rules in 
order to declare parameters which themselves have functional types. Epigram has 
'hypothetical hypotheses' hereditarily.As before, these rules indicate points where 
variables should be generalised where possible. Correspondingly, it is sometimes 
necessary to insert an (untyped) declaration at an outer level, in order to suppress 
generalisation at an inner level. For example, in the declaration of kit, it's important 
that each operation is general with respect to contexts and types, but they should 
all apply to a fixed instance of '♦', hence its explicit declaration. 

How do we traverse a term, given a Kit? In general, we have a type-preserving 
map r from variables over context T to stuff over A. We can push that map through 
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terms in a type-preserving way as follows: 



K : Kit (♦) T,A 



x : T3 X 



t : T ► T 



let 



r x : A ♦ X 



trav K t t : A ► T 



trav K t t <= rec < { 
trav K t t <= case £ { 
trav if r (var x) <J= case if { 

trav (kit vr tm wk) r (var x) =>■ tm (r a;) } 
trav if t (Ida £') =^ Ida (trav if (lift if t) £') 
trav if r (app / s) => app (trav if r /) (trav if t s) }} 



Epigram programs are tree-structured. The nodes, marked with symbols 
(pronounced 'by'), explain how to refine the problem of delivering an output from 
the inputs, by invoking 'eliminators' which specify problem-decomposition strate- 
gies, such as structural recursion or case analysis. The leaves, marked with '=>' 
symbols (pronounced 'return'), indicate the output which the program should pro- 
duce in a given case. Informally, you can imagine that the program only consists 
of leaves, defined by pattern matching. More formally, the program is checked with 
respect to its eliminators — each of the case nodes is exhaustive, and the recursive 
calls are checked to be structural with respect to the parameter indicated in the 
rec node. This program is thus seen to be total. 

In the var case, our map r gives us some stuff, which we can turn into a term 
with some help from our kit. The other two cases go with structure, but we shall 
need to lift r to source and target contexts extended by a bound varaible, in order 
to push it under a binder — we shall sec how to do this in a moment. The rules of 
the simply-typed A-calculus are respected without a squeak! 

Note that the 'patterns' to the left of '-<=' or ' => ' were not written by me, but 
by the editor, provoked by my choices of eliminator. The notation may be a touch 
verbose, but the effort involved is less than usual. This somewhat austere notation 
allows for the possibility of user-defined eliminators, rather than rec and case , a 
possibility explored more fully in 'The view from the left' (McBride & McKinna, 
2004), but it could readily be tuned to privilege normal behaviour, suppressing case 
eliminators inferrable from the constructor symbols in patterns. 

But I digress, when I should be writing lift. This just maps the new variable to 
itself (or rather, its representation as 'stuff'), and each old variable to the weakening 
of its old image. 



if : Kit (♦) T, A 



x : T 9 X 



x : TzS 3 T 



let 



r x : A 4 X 



lift if t x : A:S ♦ T 



lift K t x <= case if { 
lift (kit vr tm wk) t x <S= case i { 
lift (kit vr tm wk) r vz vr vz 

lift (kit vr tm wk) t (vs x) wk (r x) }} 
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From here, renaming and substitution are easy! We just need to construct the 
kits for '9' and '►' respectively. 

r,A x : r A X y t :T>T 
p x : A 9 A 

let 

— rename p t : A ► T 

rename p t => trav (kit id var vs) p t 

The identity function makes variables from variables; the var constructor takes vari- 
ables to terms; the vs constructor weakens each variable into an extended context. 
Meanwhile, substitution goes like this: 

T,A x : T /?^ Y t :T>T 
ax : A ► A 

lot 

— subst a t : A ► T 

subst a t =>■ trav (kit var id (rename vs)) a t 

That is, var makes terms from variables, id takes terms into terms, and a term is 
weakened by renaming with vs. 



4 Conclusion and Further Work 
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